home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 1 / Cream of the Crop 1.iso / PROGRAM / TP122591.ARJ / 12-25-91.TPC
Text File  |  1991-12-25  |  78KB  |  2,350 lines

  1.  
  2. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3.  
  4. Conference 4
  5. Date       12-18-91 01:42:40
  6. From       Trevor Carlsen
  7. To         John Gohde
  8. Subject    Re: Proposed Turbo Enhanc
  9.  
  10.  TCID:6c34584c 40d3
  11. JG>... Borland  is reported to  be ready to  release TP7...
  12.  
  13. Who says!!?
  14.  
  15. I'll make a small wager!  There will be NO TP7 released in the next 6 months!
  16.  
  17. (I'd really like to say 12 months but feel that could be stretching my luck
  18. a little as who knows what Topspeed or SB might come up with in the meantime
  19. and force Borland's hand.  At the moment they don't represent real competition
  20. but they're
  21. getting there!)
  22.  
  23. Borland reportedly releases their new versions about now.  If a new version
  24. IS about to be released, I'll bet it is not 7.0.
  25.  
  26. P.S.  I'll not take bets from you beta testers out there!! :-)
  27.  
  28. TeeCee
  29.  
  30. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  31.  
  32.  
  33. --- Dogfight 2.06 #2
  34.  
  35.  
  36. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  37.  
  38. Conference 4
  39. Date       12-18-91 09:07:40
  40. From       Terry Hughes
  41. To         Jud Mccranie
  42. Subject    Turbo Analyst
  43.  
  44.  In a message to Terry Hughes <10 Dec 91 13:11:00> Jud Mccranie wrote:
  45. JM> Sometimes I use the "optimize uses" option, then modify my main program
  46. JM> to list the units in that order.  How does this help - i.e. does it
  47. JM> compile or link faster?
  48. It makes it easier for the compiler to parse the uses list
  49. because each new TPU is introduced to the compiler in dependency
  50. order. This offers a very slight increase in performance
  51. (because it results in fewer file open/closes) and it avoids
  52. wasting space in a least one compiler table (the $DEFINES
  53. table).
  54. Where there are truly no dependency differences the TPU order
  55. doesn't matter. It sounds like the two units you are being asked
  56. to exchange have equal dependency. I'll pass that along to Kim,
  57. the keeper of PSA, to see if there's some way he can detect and
  58. preserve the current uses order when it doesn't need to be
  59. changed.
  60. JM> it just means that SOME proc in unit A calls SOME proc in B, and that
  61. JM> SOME proc in B calls SOME proc in A - not necessarily a circular
  62. JM> reference.  It would be nice if TA could tell what the real culprits
  63. JM> like that are circular so they could be put into the same unit.  It
  64. JM> would be nicer still if TA could recomend which procs should go into
  65. JM> which unit.
  66. The Overlay Linkages report isn't trying to show circular
  67. references. It's trying to show that both the caller and the
  68. target are both in overlayed units -- meaning that an overlay
  69. load may be required. I think your point is still valid though
  70. (that it would be nice to know which procedures are making the
  71. calls). I'll pass the suggestion along to Kim.
  72. -Terry
  73. P.S. Sorry for the delay in responding.
  74. * Origin: TurboPower Software voice 719-260-6641 (Quick 1:208/2.3)
  75.  
  76.  
  77. --- Dogfight 2.06 #2
  78.  
  79.  
  80. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  81.  
  82. Conference 4
  83. Date       12-18-91 09:26:00
  84. From       Terry Hughes
  85. To         Ken Sallot
  86. Subject    B-tree Filer
  87.  
  88.  In a message to Terry Hughes <15 Dec 91 02:31:00> Ken Sallot wrote:
  89. KS> Why is it that almost any program I write using Opro
  90. KS> (and I must admit MAKEMENU and MAKESCRN), can't be
  91. KS> PKLite'd? It usually just gives me a nice
  92. KS> little QEMM exemption error #13.. Kinda wierd..
  93. I'm not a regular user of PKLite so I don't have any good
  94. ideas about why it would behave this way for OPRO programs. Do
  95. you get the exception 13 from PKLite or the compressed
  96. program?
  97. I just tried it on 3 or 4 OPRO programs (including
  98. MAKEMENU) and it worked just fine.
  99. KS> Another question I have for you, recently I've started using
  100. KS> OOVREC for the message structures on my BBS system.. My
  101. KS> understanding is there is no real way to get the # of records
  102. KS> in a VREC file, because they're broken down into
  103. KS> my predefined packet size (i.e. 256 bytes) for each "record"
  104. KS> in the file.. Am I incorrect in this assumption?
  105. Sort of... <g>
  106. You can't use BTUsedRecs since it will return the number of used
  107. sections rather than logical records. The usual solution is to
  108. use BTUsedKeys (assuming that you have a key where one and only
  109. one key value exists for each logical record).
  110. -Terry
  111. * Origin: TurboPower Software voice 719-260-6641 (Quick 1:208/2.3)
  112.  
  113.  
  114. --- Dogfight 2.06 #2
  115.  
  116.  
  117. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  118.  
  119. Conference 4
  120. Date       12-18-91 09:45:30
  121. From       Terry Hughes
  122. To         George Mcnamara @ 972/2
  123. Subject    Mark/release For ems?
  124.  
  125.  In a message to All <10 Dec 91 23:45:00> George Mcnamara @ 972/2 wrote:
  126. GM> Does anyone (i.e. Terry Hughes of Turbo Power) have a utility to free
  127. GM> EMS memory, similar to Turbo Power's mark and release for conventional
  128. GM> memory?  I'm in the middle of a project that uses a bunch of large Turbo
  129. GM> Power TpArray's in EMS, and my programs frequently crash before reaching
  130. GM> the tpearray.disposeA(myarray); statements (each crash results in losing
  131. GM> access to the allocated EMS.
  132. The first thing that comes to mind is to install an exit proc
  133. that calls DisposeA(MyArray) on crashes. There's a reason that
  134. we don't do this automatically but it escapes me right now.
  135. And note that RELEASE already restores EMS memory to the state it
  136. had when MARK was run.
  137. -Terry
  138. * Origin: TurboPower Software voice 719-260-6641 (Quick 1:208/2.3)
  139.  
  140.  
  141. --- Dogfight 2.06 #2
  142.  
  143.  
  144. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  145.  
  146. Conference 4
  147. Date       12-18-91 12:22:10
  148. From       Terry Hughes
  149. To         Jud Mccranie
  150. Subject    B-tree Filer
  151.  
  152.  In a message to Terry Hughes <15 Dec 91 21:56:00> Jud Mccranie wrote:
  153. JM> I want to it just won't fit.  So I say it is very nice, but impractical
  154. JM> if you want to actually use it in a large program.
  155. You'll have a tough time convincing the majority of OPRO users
  156. of that (particularly the ones successfully marketing large
  157. OPRO-based programs <g>).
  158. JM> They must doing smaller programs.
  159. No, in supporting our OPRO customers I find that most are
  160. writing rather large and complex programs and systems. In fact,
  161. the benefits of OPRO are more obvious in large programs than
  162. small programs. If your program has one entry screen it will
  163. seem overly large for that one simple function (because of all
  164. the low-level window support code linked in). However, if your
  165. program has several dozen entry screens, menus, picklists and so
  166. on, the low-level window code is shared by all those higher
  167. level objects.
  168. JM> But what good is it if you can't fir the program in memory?
  169. Do you mean when compiling the program or when running the
  170. compiled program?
  171. If you mean "not enough memory to compile the program" then the
  172. solutions are to use TPC or TPCX. I noticed in another message
  173. that you use the IDE. The IDE does a lousy job of memory
  174. management and severly limits the size of a program you can work
  175. with. Most programmers I know that are involved in large
  176. projects gave up the IDE long ago for one of the many
  177. programmer's editors on the market. The editor we use in house
  178. at TurboPower Software, TPE, is free (you can get it from our
  179. files BBS at 719-260-9726).
  180. If you mean "not enough memory to run the program" then it
  181. becomes a program design issue. Apparently, many programmers are
  182. finding ways to make their programs fit. The largest single
  183. Turbo Pascal program I've seen consisted of a 300K EXE and a 1.7
  184. megabyte overlay file. This huge program still ran nicely on a
  185. 640K machine. And I know of projects that weigh in even larger
  186. than this by breaking the tasks at hand into multiple EXEs.
  187. As programmers we all get a thrill out of making our programs as
  188. small and fast as possible. If I'm writing some little ditty for
  189. myself I'll sometimes forsake library code as I try to make my
  190. routines small and fast (and because I enjoy that kind of
  191. programming). When competing for programming contracts, however,
  192. I find that most clients are more concerned with low prices for
  193. the features they require and less concerned with EXE size (if
  194. they care at all).
  195. I also try to avoid generalizing those things that I think are
  196. good into "the universally correct way." OPRO works for me and a
  197. lot of other people because it offers what we need. If its
  198. negatives outnumber the positives for you then sticking with
  199. TPRO is the right choice (for you). But your generalization of
  200. "impractical" just doesn't hold water considering all of the
  201. people using OPRO in very practical ways.
  202. JM> What is the current version of TPro?  (I have 5.09 beta)
  203. We just started shipping 5.13.
  204. -Terry
  205. * Origin: TurboPower Software voice 719-260-6641 (Quick 1:208/2.3)
  206.  
  207.  
  208. --- Dogfight 2.06 #2
  209.  
  210.  
  211. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  212.  
  213. Conference 4
  214. Date       12-18-91 12:37:40
  215. From       Terry Hughes
  216. To         Jud Mccranie
  217. Subject    Tpro
  218.  
  219.  In a message to Terry Hughes <15 Dec 91 21:56:00> Jud Mccranie wrote:
  220. JM> I haven't gotten anything since the "move to CO. card".  I moved since
  221. JM> then, but I told the P.O. to forward my mail.  If you'll relay my new
  222. JM> address it is 1503 East Park Ave, V-11; same city and zip.  Thanks.
  223. Got it. I'll update your address in our database.
  224. -Terry
  225. * Origin: TurboPower Software voice 719-260-6641 (Quick 1:208/2.3)
  226.  
  227.  
  228. --- Dogfight 2.06 #2
  229.  
  230.  
  231. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  232.  
  233. Conference 4
  234. Date       12-19-91 09:36:00
  235. From       Trevor Carlsen
  236. To         Clayton Ainsworth
  237. Subject    Re: keyboard buffer
  238.  
  239.  TCID:6e8af806 4154
  240. CA> Have you considered using ReadKey, which doesn't use the buffer?
  241.  
  242. Really?  Of course it uses the buffer.
  243.  
  244. TeeCee
  245.  
  246. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  247.  
  248.  
  249. --- Dogfight 2.06 #2
  250.  
  251.  
  252. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  253.  
  254. Conference 4
  255. Date       12-19-91 09:38:30
  256. From       Trevor Carlsen
  257. To         Jesse Scott
  258. Subject    64k Limit?!
  259.  
  260.  TCID:bcf98735 4155
  261. JS> I am trying to make a multi-dimensional array of this record here:
  262. JS> type
  263. JS>   bit = 0..50;
  264. JS>   rooms = record
  265. JS>     desc : string[80];
  266. JS>     mc : bit;
  267. JS>     tc : bit;
  268. JS>     perm_mons : array [1..5] of monsters;
  269. JS>     perm_item : array [1..5] of items;
  270. JS>   end;
  271.  
  272. JS> var
  273. JS>   room : array[1..1000,1..1000,1..10] of rooms;
  274.  
  275. JS> I keep getting an Error saying "Structure To Large"...
  276.  
  277. I'm not surprised!  Assuming the monsters and items types are single bytes
  278. that structure would require (81+1+1+5+5) * 1000 * 1000 * 10 bytes.  That's
  279. 930,000,000 bytes!  Mmmm...
  280.  
  281. {$TONGUE_IN_CHEEK+}
  282. You will have to set up a disk file of rooms and as you need any particular
  283. record seek to that record.  Say you want the record [56,999,7], you will
  284. need to seek to 55*998*6 or 329,340.
  285. {$TONGUE_IN_CHEEK-}
  286.  
  287. I think you have a major rethink needed.
  288.  
  289. TeeCee
  290.  
  291.  
  292.  
  293. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  294.  
  295.  
  296. --- Dogfight 2.06 #2
  297.  
  298.  
  299. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  300.  
  301. Conference 4
  302. Date       12-19-91 16:29:10
  303. From       Trevor Carlsen
  304. To         Jud Mccranie
  305. Subject    Pascal Books And Tutoria
  306.  
  307.  TCID:279b0414 4157
  308. JM> ...  But the IDE gives you the advantage of the
  309. JM> integrated debugger and very quick compiles from within
  310. JM> the editor.  If you have a syntax error it puts you
  311. JM> right back in the editor with the cursor on the error,
  312. JM> etc.  You can break the program and it puts you in the
  313. JM> editor. ...
  314.  
  315. With my set up all those features are available to me using QEdit.
  316.  
  317. JM> From there you can evaluate (or change) the contents of
  318. JM> variables, step through the program, etc. I have to
  319. JM> have a pretty bad bug to resort to TD.  It is as bad or
  320. JM> worse as using a seperate editor.
  321.  
  322. I guess that is a subjective judgement.  I rarely need to use TD so it is
  323. not really an issue for me.
  324.  
  325. TeeCee
  326.  
  327. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  328.  
  329.  
  330. --- Dogfight 2.06 #2
  331.  
  332.  
  333. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  334.  
  335. Conference 4
  336. Date       12-19-91 16:23:20
  337. From       Trevor Carlsen
  338. To         Mike Copeland
  339. Subject    Delete procedure
  340.  
  341.  TCID:775066ae 4156
  342. TC>   var
  343. TC>     St  : string;
  344. TC>     len : byte absolute St;
  345. TC>
  346. TC>   while St[len] = ' ' do dec(len);
  347.  
  348. MC>    I do it slightly differently, and I have found situations (the
  349. MC> string is all blanks) which cause infinite loops. Thus, I do the
  350. MC> following:
  351.  
  352. MC>   while (Length(S) > 0) and (S[Length(S)] = ' ') do
  353. MC>     Dec (S[0])
  354.  
  355. The method I demo'd above *cannot* enter an infinite loop, regardless of
  356. whether the string is all blanks or not.   However that method *could* loop
  357. infinitely if a string was all nuls and the character being deleted was a
  358. nul.
  359.  
  360. TeeCee
  361.  
  362. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  363.  
  364.  
  365. --- Dogfight 2.06 #2
  366.  
  367.  
  368. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  369.  
  370. Conference 4
  371. Date       12-19-91 10:42:40
  372. From       Trevor Carlsen
  373. To         Ken Burrows
  374. Subject    Delete procedure
  375.  
  376.  TCID:77500130 4158
  377. TC>   var
  378. TC>     St  : string;
  379. TC>     len : byte absolute St;
  380.  
  381. TC>   while St[len] = ' ' do dec(len);
  382.  
  383. KB> This also works : while st[length(st)] = ' ' do dec(st[0]);
  384.  
  385. Sure does!  But it is still marginally slower due to the little bit of extra
  386. processing that the length "function" does.  I put function in quotes because
  387. it is not a true function in the sense that it uses the stack and passes
  388. parameters etc.
  389.  If it was a true function then, of course, it would be very much slower
  390. indeed.
  391.  
  392. TeeCee
  393.  
  394. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  395.  
  396.  
  397. --- Dogfight 2.06 #2
  398.  
  399.  
  400. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  401.  
  402. Conference 4
  403. Date       12-19-91 11:51:30
  404. From       Trevor Carlsen
  405. To         Matt Farrenkopf
  406. Subject    inserting text into executable code
  407.  
  408.  TCID:5c938ad0 4159
  409. MF> Haven't tested it, but I believe an easier way to do that is to just
  410.  
  411. MF> say
  412.  
  413. MF> CONST
  414. MF>   CopyrightString : STRING = 'This program is copyright 1991 by Pirate
  415. MF>     Software';
  416.  
  417. Unless the string is actually USED somewhere (or another constant from the
  418. same declaration part is used), it will not appear in the exe because it
  419. will have been stripped by the smart linker.
  420.  
  421.  
  422. TeeCee
  423.  
  424. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  425.  
  426.  
  427. --- Dogfight 2.06 #2
  428.  
  429.  
  430. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  431.  
  432. Conference 4
  433. Date       12-19-91 16:21:50
  434. From       Trevor Carlsen
  435. To         Matt Farrenkopf
  436. Subject    Dispose and Release
  437.  
  438.  TCID:f09d2736 415a
  439. MF> I don't fully understand the problem with using Dispose with Release.
  440. MF> For example, with the following code blurb (written online):
  441.  
  442. MF> VAR
  443. MF>   P1 : POINTER;
  444. MF>   P2 : POINTER;
  445. MF>   P3 : POINTER;
  446. MF>   Ptr4Heap : POINTER;
  447.  
  448. MF> BEGIN
  449. MF>   Mark(Ptr4Heap);
  450. MF>   New(P1);
  451. MF>   New(P2);
  452. MF>   New(P3);
  453. MF>   Dispose(P2);
  454. MF>   Release(Ptr4Heap);
  455. MF> END.
  456.  
  457. MF> What is wrong with using it in this method?  It seems to me that all
  458.  
  459. MF> that would happen is that P1 and P3 would effectively be disposed,
  460. MF> while P2 has already been disposed of.
  461.  
  462. There is nothing wrong in using the above method as long as you fully understandthe possible ramifications in a real program.  When you use release the freelistif there is one, is lost.  That means that any free heap space amongst heap
  463. data
  464. that was present BEFORE the mark procedure was used is lost.  Perhaps an
  465. example is the easiest way to explain -
  466.  
  467.  begin
  468.    new(p1);
  469.    new(p2);
  470.    new(p3);
  471.    dispose(p2);
  472.    mark(ptr4heap);
  473.    new(p4);
  474.    new(p5);
  475.    release(ptr4heap);
  476.  
  477. Now the free space that was formerly used by p2^ is lost.
  478.  
  479. TeeCee
  480.  
  481. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  482.  
  483.  
  484. --- Dogfight 2.06 #2
  485.  
  486.  
  487. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  488.  
  489. Conference 4
  490. Date       12-19-91 16:38:10
  491. From       Trevor Carlsen
  492. To         Richard Van Fossan
  493. Subject    Pascal capabilities
  494.  
  495.  TCID:30f86a38 415b
  496. RV> ... those are NOT standard Pascal. I was comparing the features of
  497. RV> ANSI C to those of ANSI Pascal...
  498.  
  499. Where did you get the ANSI Pascal standard from?  The latest standard Pascal
  500. extracts I have seen give the language a lot of the goodies that TP has and
  501. a few more besides.  It is a very powerful language.
  502.  
  503. If anybody has a copy of the latest ANSI document, or where to get it, I
  504. would appreciate it.
  505.  
  506. TeeCee
  507.  
  508. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  509.  
  510.  
  511. --- Dogfight 2.06 #2
  512.  
  513.  
  514. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  515.  
  516. Conference 4
  517. Date       12-19-91 19:59:20
  518. From       Trevor Carlsen
  519. To         Douglas Delonay
  520. Subject    Setting bits and com routines
  521.  
  522.  TCID:328f1f0c 415c
  523. DD>   I have been trying to get a program to use a FOSSIL with AMFOSSIL,
  524.  
  525. DD> but been running into a small(??) problem. To set the baud rate it
  526. DD> asks for a mask? by the DOCS it wants to be sent the mask with
  527. DD> apropriate bits set instead of a numeric representation of the baud
  528.  
  529. DD> rate. I have no, or very little knowledge of how to do this. I would
  530.  
  531. DD> greatly appreciate it if someone would be kind enough to post some
  532. DD> code on how to use the SETBAUDRATE procedure in AMFOSSIL by setting
  533.  
  534. DD> bits in TP 6.0.
  535. DD>   Also if you could direct me to a good book on the basics on setting
  536.  
  537. DD> bits with good examples and detailed explanations. Keep in mind I'm
  538. a
  539. DD> complete novice at this. I need it to explain the basics!. Most
  540. DD> documentation I've seen on the subject seems to assume that I know how
  541.  
  542. DD> to set the bits etc.
  543.  
  544. Setting bits (turning them on), resetting bits (turning them off), testing
  545. the status of bits etc., all involve logical operations.
  546.  
  547. You are probably aware that a byte is made up of 8 bits numbered 0..7. Each
  548. of these bits represents a number to the power of 2.  So a byte with the
  549. bit pattern 00100000 which has bit 5 set is equal to 2 to the 5th power or
  550. 32.   Start by studying
  551. up on truth tables.
  552.  
  553. To turn any particular bit on it is necessary to OR the variable with the
  554. value that bit represents.  To turn the bit of it must be ANDed with 255
  555. minus the value represented by that bit.
  556.  
  557. Let's look at an example.  If you wish to set bit 5 then to set bit 5 in
  558. a variable called "numb" you say -
  559.  numb := numb or 32;
  560. To turn it of you say -
  561.  numb := numb and (255 - 32);
  562.  
  563. Now those are better expressed by the following which are more suited to
  564. a function.
  565.  numb := numb or (1 shl 5);
  566.  numb := numb and not(1 shl 5);
  567.  
  568. So the three routines can be expressed as:
  569.  
  570.  function BitIsOn(numb,bit: byte): boolean;
  571.    begin
  572.      BitIsOn := odd(numb shr bit);
  573.    end;
  574.  
  575.  procedure SetBit(var numb: byte; bit: byte);
  576.    begin
  577.      numb := numb or (1 shl bit);
  578.    end;
  579.  
  580.  procedure ResetBit(var numb: byte; bit: byte);
  581.    begin
  582.      numb := numb and not (1 shl bit);
  583.    end;
  584.  
  585. TeeCee
  586.  
  587. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  588.  
  589.  
  590. --- Dogfight 2.06 #2
  591.  
  592.  
  593. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  594.  
  595. Conference 4
  596. Date       12-19-91 18:57:00
  597. From       Jim Wilcox
  598. To         Jesse Scott
  599. Subject    64k limit?!
  600.  
  601.  JS>I am trying to make a multi-dimensional array of this record here:
  602.  
  603. JS>-------------------------------------------------------
  604.  
  605. JS>program Test;
  606.  
  607. JS>type
  608. JS>  bit = 0..50;
  609. JS>  rooms = record
  610. JS>    desc : string[80];
  611. JS>    mc : bit;
  612. JS>    tc : bit;
  613. JS>    perm_mons : array [1..5] of monsters;
  614. JS>    perm_item : array [1..5] of items;
  615. JS>  end;
  616.  
  617. JS>var
  618. JS>  room : array[1..1000,1..1000,1..10] of rooms;
  619.  
  620. JS>-------------------------------------------------------
  621.  
  622. JS>I keep getting an Error saying "Structure To Large", It has to be
  623. JS>smaller or equal to 64k, How do I get around this?... I get the same
  624. JS>error in C also :)...
  625.  
  626.  
  627. JS>            --------> JScott
  628. JS>P.S. The error is in the array part :)
  629.  
  630. To begin with, you would need 860 megabytes to do what you want to do and
  631. that is not including the items and the monsters.  What you need to do once
  632. you decide on a reasonable limit is to break your array down into smaller
  633. units as types and
  634. then name a type that is a pointer to them, then set up an array to allocate
  635. them using NEW.
  636.  
  637. type
  638.        roomptr : ^rooms;
  639.  
  640.        i, j, k : integer;
  641.  
  642.        room : array[1..32,1..10,1..10] of roomptr;
  643.  
  644. begin
  645.  
  646.        for i := 1 to 32 do
  647.        begin
  648.                for j := to 10 do
  649.                begin
  650.                        for k := 1 to 10 do
  651.                                new(room[i,j,k];
  652.                end;
  653.        end;
  654. end;
  655.  
  656.  
  657. Jim
  658. ===
  659. * SLMR 2.0 * 3 miles west of civilization and heading for the sunset!
  660.  
  661.  
  662. * Origin: DIXIELAND BBS - Macon, Ga. 912-471-1243 >HSTs< (1:3611/2)
  663.  
  664.  
  665. --- Dogfight 2.06 #2
  666.  
  667.  
  668. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  669.  
  670. Conference 4
  671. Date       12-20-91 06:23:30
  672. From       Trevor Carlsen
  673. To         Greg Smith
  674. Subject    TTT units
  675.  
  676.  TCID:32000a0b 41a3
  677. GS> If you're looking for a couple simple non-critical (18.2ms resolution)
  678.                                                         ^^^^^^
  679. GS> timing routines, here's what I developed for my IEMSI unit:
  680.  
  681. That should be 55ms.  (18.2 times per second or (1000 / 18.2)ms)
  682.  
  683. TeeCee
  684.  
  685. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  686.  
  687.  
  688. --- Dogfight 2.06 #2
  689.  
  690.  
  691. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  692.  
  693. Conference 4
  694. Date       12-20-91 06:27:20
  695. From       Trevor Carlsen
  696. To         Jim Wilcox and All
  697. Subject    Com unit
  698.  
  699.  TCID:63b5aeaf 41a4
  700. JW> I have written a COM unit that will allow fast easy access to COM
  701. JW> ports in PASCAL.  I need a few beta testers.  If anyone is interested,
  702.  
  703. JW> please send a reply with a list or your requirements for a COM unit.
  704.  
  705. By netmail ONLY please.
  706.  
  707. Trevor Carlsen
  708. Moderator.
  709.  
  710. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  711.  
  712.  
  713. --- Dogfight 2.06 #2
  714.  
  715.  
  716. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  717.  
  718. Conference 4
  719. Date       12-20-91 09:57:40
  720. From       Trevor Carlsen
  721. To         Lincoln Dale
  722. Subject    Delete procedure
  723.  
  724.  TCID:77503851 41a8
  725. >  while (Length(S) > 0) and (S[Length(S)] = ' ') do
  726. >    Dec (S[0])
  727. > Don't know if this is horribly slow, but this is what
  728. > works soundly for me...
  729.  
  730. LD> Your method is horridly slow.  Calling the function
  731. LD> length() twice for every trailing space!
  732.  
  733. That is what I thought too... in fact I entered a reply to that same message
  734. stating similar.  However having been burned rather badly in the past by
  735. not testing assertations, I tried it.
  736.  
  737. Result? - One scrubbed out reply!!  There is a difference but it is so minor
  738. as to be almost irrelevant.  Testing was on 10000 strings of 255 spaces.
  739. Here are the results. (All times were taken using a microsecond resolution
  740. timer.)
  741.  
  742.  
  743. {***** Test 1 *****  Testing length > 0 and standard length function }
  744. while (length(st) > 0) and (st[length(st)] = ' ') do dec(st[0]);
  745. Result was - Elapsed time =   6.182675 seconds
  746.  
  747. {***** Test 2 *****  Same as test 1 but delete the test for zero length }
  748.  
  749. while st[length(st)] = ' ' do dec(st[0]);
  750. Result was - Elapsed time =   5.229914 seconds
  751.  
  752. {***** Test 3 ***** Same as test 2 but substitute absolute var for length
  753. }
  754. while st[len] = ' ' do dec(len);
  755. Result was - Elapsed time =   4.979544 seconds
  756.  
  757. {***** Test 4 ***** Same as test 1 but substitute special length function
  758. }
  759. while (StrLen(st) > 0) and (st[StrLen(st)] = ' ') do dec(st[0]);
  760. Result was - Elapsed time =  33.856099 seconds
  761.  
  762. {***** Test 5 ***** Same as test 4 but zero length test deleted }
  763. while st[StrLen(st)] = ' ' do dec(st[0]);
  764. Result was - Elapsed time =  18.961589 seconds
  765.  
  766. Now the critical examples are 2 and 3 and the difference is negligible. Note
  767.  
  768. that when a genuine function is used the timings are very slow comparatively
  769.  
  770. speaking.
  771.  
  772. Do you have the Eagle Performance Software package for TP6? If so I'll FREQ
  773. it from you if you can netmail me a file name.
  774.  
  775. TeeCee
  776.  
  777.  
  778. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  779.  
  780.  
  781. --- Dogfight 2.06 #2
  782.  
  783.  
  784. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  785.  
  786. Conference 4
  787. Date       12-20-91 10:29:30
  788. From       Trevor Carlsen
  789. To         Chad Alex
  790. Subject    variables > 64k
  791.  
  792.  TCID:7916d68f 41a9
  793. CA> Does any one know if there is a way around the 64k limit for global
  794. CA> variables?  I keep running into this when I try to compile my program.
  795.  
  796.  
  797. IMHO there is something seriously wrong with the fundamental design of any
  798. program that needs more than 64K for *global* variables.  You need to place
  799. your large structures onto the heap.
  800.  
  801. TeeCee
  802.  
  803. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  804.  
  805.  
  806. --- Dogfight 2.06 #2
  807.  
  808.  
  809. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  810.  
  811. Conference 4
  812. Date       12-21-91 08:22:30
  813. From       Trevor Carlsen
  814. To         Vince Laurent
  815. Subject    Re: BASM Query #2
  816.  
  817.  TCID:7179209a 41dd
  818. VL> I ain't worried about the WHERE did the NAME come from, just WHY
  819. VL> I have to about removing the files using a DOS command instead of
  820. VL> TURBO removing them.
  821.  
  822. You have almost certainly exitted the turbo IDE abnormally at some time,
  823. thus preventing turbo's housekeeping to take effect. A lock-up requiring
  824. a reboot, power outage or a simple reboot from the IDE would all cause the
  825. problem.
  826.  
  827. TeeCee
  828.  
  829. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  830.  
  831.  
  832. --- Dogfight 2.06 #2
  833.  
  834.  
  835. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  836.  
  837. Conference 4
  838. Date       12-21-91 05:19:00
  839. From       Trevor Carlsen
  840. To         Vince Laurent
  841. Subject    Hi-bit characters in your messages
  842.  
  843.  TCID:894d9659 41d8
  844. Please remove the hi-bit characters your reader is placing in the quoted
  845. text of your messages.
  846.  
  847. Trevor Carlsen
  848. Moderator
  849.  
  850. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  851.  
  852.  
  853. --- Dogfight 2.06 #2
  854.  
  855.  
  856. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  857.  
  858. Conference 4
  859. Date       12-21-91 20:42:00
  860. From       Norbert Igl
  861. To         Fred Johnson
  862. Subject    Read Only EXE
  863.  
  864.  Hi Fred.
  865. > Does anyone know how to get the filesize of a READ-ONLY EXE file???
  866.   I wrote this some days ago, maybe you missed it.
  867. Should work with *every* file...
  868. (1176)  Tue 17 Dec 91 21:16
  869. By: Norbert Igl
  870. To: Gary Mcnickle
  871. Re: Filesize()
  872. >     I have a question:  Is there any way I can determine the file
  873. > size of a text file while accessing it from another procedure?
  874. > here's an example of the way Im doing it now:
  875. > function size_of(filename:string):longint;
  876. > var  fileof : file;
  877. > begin {$I-}
  878. >   assign(fileof,filename);
  879. >   reset(fileof);
  880. >   size_of := filesize(fileof);
  881. > end;  {  size_of  }
  882. Hi Gary,
  883.  don't you mind closing the "fileof" ....?
  884. anyway, my "private" FileSize() looks like this :
  885. uses dos;
  886. [...]
  887. funktion FileSize(P:PathStr):Longint;
  888. Var Sr : SearchRec;
  889. begin
  890.  Findfirst(P, Archive, Sr);
  891.  if DosError=0
  892.    then FileSize := Sr.Size
  893.    else FileSize := -1
  894. end;
  895. Merry Christmas and a Happy New Year,
  896.  Norbert
  897. * Origin: .42 is the answer, but what's the question? (2:241/5300.3)
  898.  
  899.  
  900. --- Dogfight 2.06 #2
  901.  
  902.  
  903. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  904.  
  905. Conference 4
  906. Date       12-21-91 20:52:00
  907. From       Norbert Igl
  908. To         Matt Farrenkopf
  909. Subject    TP and TD help needed
  910.  
  911.  > I used to do debugging through Write/Writelns too.  Aside from the
  912. > effort it takes, it's also a pain to try to hunt them down again.  I
  913. > have a tendency to put a lot of them in and forget about them.  When
  914. > I run the program, I have this statement in the middle of my display
  915. > that I forgot about.  Even worse is when the statement gets erased so
  916. > fast that I don't even see it and finally discover it months later!
  917. Since TP 4.0 ( and better ) got the "conditional compile",
  918. your problem is none.
  919. Just write :
  920. (*$DEFINE debugging *)
  921. ..  at the top of your program/unit,
  922. ..  and within the program :
  923. (*$IFDEF debugging *)
  924.   writeln(' Debug : ',  whatever_to_show );
  925. (*$ENDIF *)
  926. OR, in the IDE, set the COMPILER/DEFINES to "debugging", and debug.
  927. the final version should be compiled without this define, of course...
  928. ... maybe this helps a bit
  929. Merry Christmas and a Happy New Year,
  930.  Norbert
  931. * Origin: .42 is the answer, but what's the question? (2:241/5300.3)
  932.  
  933.  
  934. --- Dogfight 2.06 #2
  935.  
  936.  
  937. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  938.  
  939. Conference 4
  940. Date       12-21-91 11:49:00
  941. From       Jim Wilcox
  942. To         Jason Turley
  943. Subject    Re: com unit
  944.  
  945.  JT>> I have written a COM unit that will allow fast easy access
  946. JT>> to COM ports in
  947. JT>> PASCAL.  I need a few beta testers.  If anyone is
  948. JT>> interested, please send a
  949. JT>> reply with a list or your requirements for a COM unit.
  950.  
  951. JT>I would find a Pascal COM unit very useful!  I am currently writing my
  952. own B
  953. JT>software and a COM library would be of great use to me.
  954.  
  955.  
  956. What kind of functions will you need in your BBS software?  I have it so
  957. you can check DTR, CTS or carrier.  Do you have any other requirements that
  958. I might need to add?
  959.  
  960. Jim
  961. ===
  962. * SLMR 2.0 * Riding the crest of infinite!
  963.  
  964.  
  965. * Origin: DIXIELAND BBS - Macon, Ga. 912-471-1243 >HSTs< (1:3611/2)
  966.  
  967.  
  968. --- Dogfight 2.06 #2
  969.  
  970.  
  971. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  972.  
  973. Conference 4
  974. Date       12-21-91 11:52:00
  975. From       Jim Wilcox
  976. To         Chad Alex
  977. Subject    256 color vga
  978.  
  979.  CA>Does anyone out there know if there is a BGI file that allows for
  980. CA>programming of VGA graphics using 256 colors?
  981.  
  982. CA>- Chad Alex -
  983.  
  984. There is a shareware SVGA BGI unit floating out there somewhere.  I think
  985. I have a copy of it at work.  You might look locally and see if you can find
  986. it.
  987.  
  988. Jim
  989. ===
  990. * SLMR 2.0 * Nothing is foolproof! Fools are too ingenious!
  991.  
  992.  
  993. * Origin: DIXIELAND BBS - Macon, Ga. 912-471-1243 >HSTs< (1:3611/2)
  994.  
  995.  
  996. --- Dogfight 2.06 #2
  997.  
  998.  
  999. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1000.  
  1001. Conference 4
  1002. Date       12-18-91 00:02:10
  1003. From       Mark Ouellet
  1004. To         Robert Presland
  1005. Subject    Re: I'M NOT ENTERING THE
  1006.  
  1007.     On 01 Dec 91, you, Robert Presland, of 153/734.0 wrote...
  1008. RP> Is it just my system or is everyone getting some messages
  1009. RP> like these?
  1010. Robert,
  1011.        No I got them too, it seems that BBS that has the
  1012. Education or Teacher section has got it crosslinked again.
  1013. From the looks of it I would say they are using something
  1014. like RA or Qbbs, One that keeps the text seperate from the
  1015. actual text. That is why the headers are ok but the text is
  1016. either not linked in any way to the header or garbled.
  1017.        Best regards,
  1018.        Mark Ouellet.
  1019. * Origin: I'm stuck with a Virus, Ever heard of WINDOWS? (Fidonet 1:240/1.4)
  1020.  
  1021.  
  1022. --- Dogfight 2.06 #2
  1023.  
  1024.  
  1025. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1026.  
  1027. Conference 4
  1028. Date       12-18-91 00:13:40
  1029. From       Mark Ouellet
  1030. To         Britt Van Suchtelen
  1031. Subject    Re: pointers
  1032.  
  1033.     On 25 Feb 91, you, Britt Van Suchtelen, of 2:281/515.100 wrote...
  1034. BV> Now it works, but I'd like to know why the carrets are needed. Could
  1035.  
  1036. BV> anyone please shed some light on this?
  1037. Britt,
  1038.        Seg(p) is the segment of P ITSELF
  1039.        Seg(p^) is the Segment of whatever P POINTS TO which
  1040.        is what you really wanted in the first place.
  1041.        Best regards,
  1042.        Mark Ouellet.
  1043. * Origin: I'm stuck with a Virus, Ever heard of WINDOWS? (Fidonet 1:240/1.4)
  1044.  
  1045.  
  1046. --- Dogfight 2.06 #2
  1047.  
  1048.  
  1049. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1050.  
  1051. Conference 4
  1052. Date       12-18-91 01:07:50
  1053. From       Mark Ouellet
  1054. To         Trevor Carlsen
  1055. Subject    Re: Telephone Number Form
  1056.  
  1057.     On 02 Dec 91, you, Trevor Carlsen, of 3:690/644.0 wrote...
  1058. TC>> Do you have an ISBN number please Dave?
  1059. GS>> Just out of curiosity, what can one do with an ISBN number?  Is
  1060. GS>> there
  1061. GS>> some way/where that you can look up who might have that book?
  1062. TC> A good bookshop has, or is on-line to, a complete database of books
  1063.  
  1064. TC> available.  The ISBN enables a quick and accurate look-up.
  1065. And it stands for Internationnal Serial Book Number.
  1066.        Best regards,
  1067.        Mark Ouellet.
  1068. * Origin: I'm stuck with a Virus, Ever heard of WINDOWS? (Fidonet 1:240/1.4)
  1069.  
  1070.  
  1071. --- Dogfight 2.06 #2
  1072.  
  1073.  
  1074. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1075.  
  1076. Conference 4
  1077. Date       12-19-91 18:30:20
  1078. From       Mark Ouellet
  1079. To         Frank Livaudais
  1080. Subject    Re: Records
  1081.  
  1082.     On 06 Dec 91, you, Frank Livaudais, of 1:130/78.1 wrote...
  1083. FL> How can I read the user file and have it create a new one, preserving
  1084.  
  1085. FL> the old values and putting a zero or a blank space (depending on whether
  1086.  
  1087. FL> it is a string or Num) and then write the new file?
  1088. Frank,
  1089.        You can't, you'll need to data structures, one to
  1090. read the old format and one to write the new one out.
  1091. If you intend the file to keep the same name then:
  1092.        1,      Rename old file,
  1093.        2,      Read record from old file into old data structure,
  1094.        3,      transfer old structure into new one,
  1095.        4,      initialise new fields,
  1096.        5,      write new structure to NEW FILE
  1097.        6,      repeate steps 2 through 5 until all records
  1098.                are converted.
  1099.        7,      close both files,
  1100.        8,      delete old file.
  1101.        If the new structure is a superset of the old one
  1102. then, make sure noth structures start out the same adding
  1103. any new fields to the end of the new structure. This way you
  1104. can create an instance of the New structure and declare the
  1105. old one to be over the new one using the absolute keyword.
  1106. This will eliminate the need to transfer the data.
  1107. This is the only way to do it. if you try reading from File
  1108. A with the old struc and try writing back to file A with the
  1109. new struc then you will lose data.
  1110. Suppose OldStruc has 3 fields and the new one has those same
  1111. 3 plus a new one. If you were to read record 1 with the old
  1112. struc and try to write back record 1 using the new struc
  1113. then you would actually rewrite record 1 but also overwrite
  1114. field # 1 of record #2 etc etc...
  1115.        Best regards,
  1116.        Mark Ouellet.
  1117. * Origin: I'm stuck with a Virus, Ever heard of WINDOWS? (Fidonet 1:240/1.4)
  1118.  
  1119.  
  1120. --- Dogfight 2.06 #2
  1121.  
  1122.  
  1123. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1124.  
  1125. Conference 4
  1126. Date       12-19-91 18:40:40
  1127. From       Mark Ouellet
  1128. To         Sysop
  1129. Subject    Re: Something New And Rare !
  1130.  
  1131.     On 06 Dec 91, you, TERRY BLOUNT, of 1:396/39.0 wrote...
  1132. TB> I got blasted big time for sending this program.  It
  1133. TB> must be against several rules, or either someone thinks
  1134. TB> I am sending secret messages about overthrowing the
  1135. TB> government. The replies I have been getting seem to
  1136. TB> indicate it is against Fidonet policy to send encrypted
  1137. TB> messages.
  1138. Yes I too have heard it was against the rules, in fact the
  1139. possibility of using such a program had been discussed here
  1140. or on another echo a while back. Problem is such things
  1141. often get out of hands. Not to mention there allready are
  1142. perfectly good software distribution nets and for allmost
  1143. every language or subject imaginable. I would personnaly
  1144. prefer to see a new echo created for such transmissions
  1145. than having to sift through hundreds of messages to see
  1146. which ones are actually readable.
  1147. TB> P.S.  The other problem was that it would cost too
  1148. TB> much.  I suppose we could say that about almost every
  1149. TB> message ...but I've sent $10 to my local hub every
  1150. TB> month for as long as I've been picking up my 8
  1151. TB> conferences for my little bbs.  Maybe I should start
  1152. TB> looking for the culprits who are wasting my money ?
  1153. TB> <grin>
  1154. TERRY,
  1155.        Not that much waste. Don't know about the other nets
  1156. but here on net 240, the LD costs of conferencing are shared
  1157. by all nodes this means that even if new nodes join in, the
  1158. nec is not making profits, the only difference is that all
  1159. nodes then pay less to get the same stuff. Oh and nodes only
  1160. pay according to the pro-rata of what they get, you get one
  1161. conference you pay for that conference only according to
  1162. what it cost to get it down here. In other words..., we're
  1163. getting our money's worth ;-)
  1164.        Best regards,
  1165.        Mark Ouellet.
  1166. * Origin: I'm stuck with a Virus, Ever heard of WINDOWS? (Fidonet 1:240/1.4)
  1167.  
  1168.  
  1169. --- Dogfight 2.06 #2
  1170.  
  1171.  
  1172. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1173.  
  1174. Conference 4
  1175. Date       12-19-91 18:59:40
  1176. From       Mark Ouellet
  1177. To         Gerald Gutierrez
  1178. Subject    Re: Case Sensitivity
  1179.  
  1180.     On 06 Dec 91, you, Gerald Gutierrez, of 1:153/715.5 wrote...
  1181. >> IMHO, C would have been a (slightly) better language if
  1182. >> it had not been case sensitive.
  1183. GG> I suppose I would partly agree with you, but then, case sensitivity
  1184. does
  1185. GG> offer it's own use as well. ( Just my point of view ), I think that
  1186. case
  1187. GG> sensitivty offers a more 'structured' environment than non-case
  1188. GG> sensitivity. It just 'looks' better, and easier to read than half small
  1189.  
  1190. GG> caps, and half capitals because the caps lock was hit by mistake and
  1191.  
  1192. GG> someone didn't bother to press it again or something. A very extreme
  1193.  
  1194. GG> example, but hey 8)
  1195. Gerald,
  1196.        Only problem is that case-sensitivity has nothing to
  1197. do with whether a program is written in lower-case or
  1198. upper-case. In fact in C, apart form the usual key-words and
  1199. the fact most of the libraries are allready written in
  1200. lower-case (Allthough TC will allow you to turn
  1201. case-sensivity linking off) you could easyly write ALL YOUR
  1202. code in uppercase without problems. The real problem is the
  1203. fact AAAAA and aaaaa are two different variables in C.
  1204.        I agree with the original poster when he says there
  1205. are no advantages to a language being case-sensitive. I
  1206. don't think Pascal would have caught on as much had it been
  1207. case-sensitive. Maybe some of this explains why languages
  1208. like COBOL slowly died (apart form its limitations) in this
  1209. particular case it's strange requirements for specific
  1210. sections to begin on no-less specific positions made it
  1211. look stupid at the least.
  1212.        Best regards,
  1213.        Mark Ouellet.
  1214. * Origin: I'm stuck with a Virus, Ever heard of WINDOWS? (Fidonet 1:240/1.4)
  1215.  
  1216.  
  1217. --- Dogfight 2.06 #2
  1218.  
  1219.  
  1220. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1221.  
  1222. Conference 4
  1223. Date       12-21-91 19:42:50
  1224. From       Mark Ouellet
  1225. To         Butch Adams
  1226. Subject    Re: Exec()
  1227.  
  1228.     On 09 Dec 91, you, Butch Adams, of 1:271/29.0 wrote...
  1229. BA> But still no result. Are we able to execute internal commands from
  1230. BA> within a TP program? I've tried loading Command.Com first but all I
  1231. get
  1232. BA> is the shell to come up and sit there with a C> staring back at me.
  1233. I
  1234. BA> would appreciate any help with this.
  1235. Butch,
  1236.        You were on the right track loading command.com to
  1237. gain redirection, what you missed is the "/C" that must be
  1238. at the begining of the command passed to command.com. The
  1239. "/C" tells command.com to execute whatever commands are
  1240. passed to it AND EXIT BACK TO THE PROGRAM THAT CALLED IT.
  1241.        This is why all you got was the "C:>", missing the
  1242. /C command.com didn't know there was a command to execute
  1243. and/or that it should have exited back when it's job was
  1244. done.
  1245.        Best regards,
  1246.        Mark Ouellet.
  1247. * Origin: I'm stuck with a Virus, Ever heard of WINDOWS? (Fidonet 1:240/1.4)
  1248.  
  1249.  
  1250. --- Dogfight 2.06 #2
  1251.  
  1252.  
  1253. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1254.  
  1255. Conference 4
  1256. Date       12-21-91 20:40:20
  1257. From       Mark Ouellet
  1258. To         Gerald Gutierrez
  1259. Subject    Re: !!!
  1260.  
  1261.     On 11 Dec 91, you, Gerald Gutierrez, of 1:153/715.5 wrote...
  1262. GG> I give the first person who successfully discovers the bug in the
  1263. GG> following function a big smile, congradulations, and a free dinner,
  1264. GG> providing it will work in my unit. 8)
  1265. I can either give you my adress so we can meet for lunch or
  1266. you can send a caterer ;-)
  1267. GG> TYPE STRN80 = STRING[80];
  1268. GG>
  1269. GG> {-------------------------------------------------------}
  1270. GG> Function StrnOf(Character: char; Sz:byte):strn80;
  1271. GG>
  1272. GG> Var
  1273. GG> TMPStrn: strn80;
  1274. GG>
  1275. GG> Begin
  1276. GG> Fillchar (TmpStrn,Sz,Character);
  1277. GG> Strnof := TMPStrn;
  1278. GG> End;
  1279. GG> Heh, okay. Give up ? Well, I suspect that I won't have
  1280. GG> the privelege of giving anyone that free dinner, since
  1281. GC> there IS no bug in the above procedure, however, it IS
  1282. GC> the piece of code that is causing me a bit of trouble.
  1283. Gerald,
  1284.        Sorry to disapoint you but *THERE IS A BUG IN IT*,
  1285. you forgot to put the length byte into offset 0.
  1286. try it this way:
  1287. TYPE STRN80 = STRING[80];
  1288. {-------------------------------------------------------}
  1289. Function StrnOf(Character: char; Sz:byte):strn80;
  1290. Var
  1291.        TMPStrn: strn80;
  1292. Begin
  1293.        Fillchar (TmpStrn,Sz,Character);
  1294.        TMPStrn[0] := Chr(Sz);     <==== ADD THIS
  1295.        Strnof := TMPStrn;
  1296. End;
  1297.        Best regards,
  1298.        Mark Ouellet.
  1299. * Origin: Stuck with a Virus, Anyone heard of Windows??? (Fidonet 1:240/1.4)
  1300.  
  1301.  
  1302. --- Dogfight 2.06 #2
  1303.  
  1304.  
  1305. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1306.  
  1307. Conference 4
  1308. Date       12-22-91 15:34:50
  1309. From       Trevor Carlsen
  1310. To         Martin Allain
  1311. Subject    Read character
  1312.  
  1313.  TCID:192700bc 4241
  1314. MA> Can anyone tell me exactly how to read a single character from the
  1315. MA> screen and store it in a string variable?  I've been able to do so
  1316. MA> with a screen but not an individual character.  Also, is it possible
  1317.  
  1318. MA> to access a Sound Blaster card from pascal and use it to play sound
  1319.  
  1320. MA> effects/music.
  1321.  
  1322. type
  1323.  video_cell    = record
  1324.                    ch  : char;
  1325.                    attr: byte;
  1326.                  end;
  1327.  video_type    = array[1..25,1..80] of video_cell;
  1328.  video_ptr     = ^video_type;
  1329. var
  1330.  screen        : video_ptr;
  1331.  video_mode    : byte absolute $40:$49;
  1332. begin
  1333.  if mode = 7 then { mono }
  1334.    screen := ptr($b000,0)
  1335.  else
  1336.    screen := ptr($b800,0);
  1337.  
  1338. Then to get an individual character just say -
  1339.  
  1340.  character := screen^[row,col];
  1341.  
  1342. There is also a BIOS interrupt to do the same thing.  ($10 function $08)
  1343.  
  1344. TeeCee
  1345.  
  1346.  
  1347. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1348.  
  1349.  
  1350. --- Dogfight 2.06 #2
  1351.  
  1352.  
  1353. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1354.  
  1355. Conference 4
  1356. Date       12-22-91 15:46:00
  1357. From       Trevor Carlsen
  1358. To         Hans Siemons
  1359. Subject    keyboard buffer
  1360.  
  1361.  TCID:6e8a42da 4242
  1362. RM> Procedure FlushKeyBoard;
  1363. RM> begin
  1364. RM>    While KeyPressed do while ReadKey <> #0 do (**);
  1365. RM> end;
  1366.  
  1367. HS> And what if the user presses an extended key? Oops...
  1368.  
  1369. Look at the code carefully.  It doesn't matter what the key is.
  1370.  
  1371. TeeCee
  1372.  
  1373. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1374.  
  1375.  
  1376. --- Dogfight 2.06 #2
  1377.  
  1378.  
  1379. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1380.  
  1381. Conference 4
  1382. Date       12-22-91 15:55:30
  1383. From       Trevor Carlsen
  1384. To         Fred Johnson
  1385. Subject    Read Only EXE
  1386.  
  1387.  TCID:67b8b679 4243
  1388. FJ> Does anyone know how to get the filesize of a READ-ONLY EXE file???
  1389.  
  1390. Check out the FileSize function in your manual.
  1391.  
  1392. TeeCee
  1393.  
  1394. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1395.  
  1396.  
  1397. --- Dogfight 2.06 #2
  1398.  
  1399.  
  1400. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1401.  
  1402. Conference 4
  1403. Date       12-22-91 16:11:00
  1404. From       Trevor Carlsen
  1405. To         John Gohde
  1406. Subject    Experience V qualifications
  1407.  
  1408.  TCID:439d7f10 4240
  1409. JG> A person   without   a   degree   documents   lack   of   effort,
  1410. JG> concentration, etc, and LACK OF PERSONAL INVESTMENT in his job.
  1411.  
  1412. JG> I am  surprised that  you would   suggest that  you can  obtain a
  1413. JG> degree in Programming without  writing programs. Writing programs
  1414. JG> is by definition programming  experience!!! The ONLY difference I
  1415. JG> have found between writing programs for school versus business is
  1416. JG> that writing  programs in a  business environment is  a whole lot
  1417. JG> easier and  more fun. On  the down side,  your BOSS is  usually a
  1418. JG> totally idiot (who  got his position 20 years  ago, when any fool
  1419. JG> could get a programming job).
  1420.  
  1421. JG> Having experience denotes NOTHING but existing.
  1422.  
  1423. JG> For  every  educated  fool,  I  have  seen 10 experienced persons
  1424. JG> totally  unqualified for  their positions.  And, who  are PLAINLY
  1425. JG> functional incompetents;
  1426.  
  1427. As an employer, and as every employer I have ever known, the PRIMARY consideratifor employing anybody is not qualifications but -
  1428. "CAN S/HE EFFECTIVELY DO THE JOB?"
  1429.  
  1430. The answer to that may *partly* be answered by qualifications.  However there
  1431. is no qualification in the world that proves how practical and competent
  1432. somebody is, none that proves how they get along with people and work within
  1433. a team, none
  1434. that proves how they react under pressure, none that proves how they react
  1435. to discipline, none that proves what sort of attitude they have etc. etc.
  1436.  
  1437.  
  1438. All those are VITAL for success in a team environment.
  1439.  
  1440. Please direct any further comments on this through netmail.
  1441.  
  1442. TeeCee
  1443.  
  1444. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1445.  
  1446.  
  1447. --- Dogfight 2.06 #2
  1448.  
  1449.  
  1450. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1451.  
  1452. Conference 4
  1453. Date       12-22-91 20:38:00
  1454. From       Norbert Igl
  1455. To         Tony Phillips
  1456. Subject    I need Help
  1457.  
  1458.  > Procedure Inc_b;
  1459. > Var Last_b : Text;
  1460. >          b : integer;
  1461. > Begin
  1462. >    b := 0;
  1463. >    Assign(Last_b,'branch.dat');
  1464. >    Rewrite(Last_B);
  1465. >    Writeln(Last_B,b);
  1466. >    Close(Last_B);
  1467. > end;
  1468. > I call this procedure from within another and it creates the file but
  1469.                              -------------------
  1470. > it is always empty afterwards. I use the same procedure elsware in my
  1471.                                                        ----------------
  1472. > program and it works fine. What could be causing this? Any help would
  1473.  ---------
  1474. > be greatly appreciated!
  1475.  Hello Tony,
  1476.   since your proc uses a 'local' File-Var,
  1477.   this strange behavior (sp?) might be caused
  1478.   from unsufficient STACK-Space..
  1479.   Try compiling this prog with (*$S+, $R+ *)
  1480.   Merry Christmas and a Happy New Year...
  1481. Bye from Germany, Norbert
  1482. * Origin: May the source be with you... (2:241/5300.3)
  1483.  
  1484.  
  1485. --- Dogfight 2.06 #2
  1486.  
  1487.  
  1488. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1489.  
  1490. Conference 4
  1491. Date       12-22-91 19:02:50
  1492. From       Mark Ouellet
  1493. To         Ken Burrows
  1494. Subject    Re: Opro/turbo Pasca
  1495.  
  1496.     On 17 Dec 91, you, Ken Burrows, of 1:249/201.21 wrote...
  1497. KB> In the current issue of PCTechniques there is a short HAX that contains
  1498.  
  1499. KB> a parser. It uses the built in parsing utility that paramstr and
  1500. KB> paramcount
  1501. KB> uses.
  1502. <code deleted to save space>
  1503. KB> Basically, it just points the built in parser to whatever string
  1504. KB> you want to parse.
  1505. KB>
  1506. KB> Lots of room for imaginative use here.
  1507. Ken,
  1508.        I was looking for a YACC parser maybe or an LALR1
  1509. parser but I'm saving this little trick for future use.
  1510. Never new paramcount and paramstr were being calculated at
  1511. the time of the call, could in deed come in handy at some
  1512. time rather than rewriting the whole routine.
  1513.        Best regards,
  1514.        Mark Ouellet.
  1515. * Origin: Stuck with a Virus, Anyone heard of Windows??? (Fidonet 1:240/1.4)
  1516.  
  1517.  
  1518. --- Dogfight 2.06 #2
  1519.  
  1520.  
  1521. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1522.  
  1523. Conference 4
  1524. Date       12-22-91 19:06:20
  1525. From       Mark Ouellet
  1526. To         Kash Sharvini
  1527. Subject    Re: Code to reboot the computer
  1528.  
  1529.     On 17 Dec 91, you, Kash Sharvini, of 1:153/722.0 wrote...
  1530. KS> So is it possible to have only complie only asm code using tp? and if
  1531.  
  1532. KS> it is, then what would you think are the disadvatages of doing so. BTW
  1533.  
  1534. KS> can you make
  1535. KS> obj files with tp? thanks
  1536. Kash,
  1537.        Yes you could easily have all your procedure be in
  1538. ASM only, the resulting .EXE or .TPU would be larger than
  1539. what Tasm would produce since BASM (The built in assembler
  1540. of TP6) would add entry and exit code to your procedure. The
  1541. reason for this is that even though you write the procedure
  1542. in assembler the fact you include it inside a TP procedure
  1543. implies you intend to use it as a normal TP procedure.
  1544.        As for producing .OBJ from TP, no you can't, it will
  1545. either compile to .TPU for units or to .EXE for the
  1546. resulting program.
  1547.        The disvantage is you can only use it from a TP
  1548. program until borland allows to directly link Tp code with
  1549. TC or Tasm etc... The advantage is that of speed, if a
  1550. routine is too slow in TP you can rewrite directly in the
  1551. program and not have to rewrite the rest of the code.
  1552.        When working in C I would often build my routine in
  1553. C first to make sure my algorithm was ok, then I would
  1554. rewrite it in assembler if it was a time critical routine.
  1555.        Best regards,
  1556.        Mark Ouellet.
  1557. * Origin: Stuck with a Virus, Anyone heard of Windows??? (Fidonet 1:240/1.4)
  1558.  
  1559.  
  1560. --- Dogfight 2.06 #2
  1561.  
  1562.  
  1563. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1564.  
  1565. Conference 4
  1566. Date       12-22-91 19:19:20
  1567. From       Mark Ouellet
  1568. To         John Gohde
  1569. Subject    Re: Obj
  1570.  
  1571.     On 16 Dec 91, you, John Gohde, of 1:264/212.0 wrote...
  1572. JG> I am  afraid  that   I  was  wrong.  The  only   thing  that  the
  1573. JG> implementation uses clause does is to allow all for circular references.
  1574. John,
  1575.        Thanks anyways, we'll just have to wait for the next
  1576. release of TP.
  1577.        Best regards,
  1578.        Mark Ouellet.
  1579. * Origin: Stuck with a Virus, Anyone heard of Windows??? (Fidonet 1:240/1.4)
  1580.  
  1581.  
  1582. --- Dogfight 2.06 #2
  1583.  
  1584.  
  1585. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1586.  
  1587. Conference 4
  1588. Date       12-22-91 19:23:50
  1589. From       Mark Ouellet
  1590. To         Joshua Kersey
  1591. Subject    Re: T.S.R
  1592.  
  1593.     On 13 Dec 91, you, Joshua Kersey, of 1:124/3108.0 wrote...
  1594. JK> -/-they said you need a spare six months!).         The task is as
  1595. JK> -/-follows:- when a key combo is pressed (such as CTRL-ALT-ESC) the
  1596.  
  1597. JK>
  1598. JK> I wouldn't suggest using that key combination, I know more than one
  1599. JK> person's BIOS/CMOS configuration is that combination.
  1600. True, but only recognised during memory test on reboots!!!
  1601.        Best regards,
  1602.        Mark Ouellet.
  1603. * Origin: Stuck with a Virus, Anyone heard of Windows??? (Fidonet 1:240/1.4)
  1604.  
  1605.  
  1606. --- Dogfight 2.06 #2
  1607.  
  1608.  
  1609. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1610.  
  1611. Conference 4
  1612. Date       12-22-91 19:57:20
  1613. From       Mark Ouellet
  1614. To         Judy Birmingham
  1615. Subject    Re: !!!
  1616.  
  1617.     On 14 Dec 91, you, Judy Birmingham, of 1:157/531.2 wrote...
  1618. JB> Gerald,
  1619. JB> I think you have to set the the first character in the string,
  1620. JB> TmpStrn[0],
  1621. JB> equal to the length of the string.  Example:
  1622. Judy,
  1623.        You are just going to have to stop, you're getting
  1624. too good at this !!! ;-)
  1625.        You saw what most others missed, I too set
  1626. tmpstrn[0] but forgot to modify the fillchar call to allow
  1627. for the length byte.
  1628.        Congrats and give us details of your nigth on the
  1629. town when you get back ;-)
  1630.        Best regards,
  1631.        Mark Ouellet.
  1632. * Origin: Stuck with a Virus, Anyone heard of Windows??? (Fidonet 1:240/1.4)
  1633.  
  1634.  
  1635. --- Dogfight 2.06 #2
  1636.  
  1637.  
  1638. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1639.  
  1640. Conference 4
  1641. Date       12-22-91 20:02:30
  1642. From       Mark Ouellet
  1643. To         Glenn Crouch
  1644. Subject    Re: Assembler
  1645.  
  1646.     On 14 Dec 91, you, Glenn Crouch, of 3:690/643.3 wrote...
  1647. GC> In a message of <Dec 07 16:53>, Greg Smith (1:104/441.8) writes:
  1648. GS>>You have to use Turbo ASM for that one.. Anyways, I wish TP had
  1649. GS>>386 code
  1650. GS>>generation capability.  32 bit registers make longint's a hell of
  1651. GS>>a lot faster.
  1652. GC> No to mention more compact and easier coding for LongInts.  Let's hope
  1653.  
  1654. GC> Borland adds a 386 Option to the next TP!!!
  1655. Make that 486 ;-)
  1656.        Best regards,
  1657.        Mark Ouellet.
  1658. * Origin: Stuck with a Virus, Anyone heard of Windows??? (Fidonet 1:240/1.4)
  1659.  
  1660.  
  1661. --- Dogfight 2.06 #2
  1662.  
  1663.  
  1664. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1665.  
  1666. Conference 4
  1667. Date       12-22-91 20:11:10
  1668. From       Mark Ouellet
  1669. To         Jack Ridgway
  1670. Subject    Re: EXECSWAP
  1671.  
  1672.     On 15 Dec 91, you, Jack Ridgway, of 1:3632/4.0 wrote...
  1673. JR> Hmm, it should be easy enough to modify the source to do that..  But,
  1674.  
  1675. JR> you might want to try Ralph Brown's SpawnO.  IMHO, it's the best exec
  1676.  
  1677. JR> swapping routine there is.  Available here as SPAWNO40.ARJ.
  1678. Jack,
  1679.        spawno is very good but is still in C isn't it???
  1680.        Best regards,
  1681.        Mark Ouellet.
  1682. * Origin: Stuck with a Virus, Anyone heard of Windows??? (Fidonet 1:240/1.4)
  1683.  
  1684.  
  1685. --- Dogfight 2.06 #2
  1686.  
  1687.  
  1688. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1689.  
  1690. Conference 4
  1691. Date       12-22-91 20:31:00
  1692. From       Mark Ouellet
  1693. To         John Gohde
  1694. Subject    Re: C Bashing ...
  1695.  
  1696.     On 11 Dec 91, you, John Gohde, of 1:264/212.0 wrote...
  1697. JG> Not at  all wrong to  knock C! It  has been my  experience that C
  1698.                           ^^^^^^^
  1699. JG> programmers  will knock  Pascal  at  every opportunity.  The most
  1700.                       ^^^^^^^^^^^^^
  1701. JG> favorite  knock is  to characterize  Pascal as  a "good  teaching
  1702.     ^^^^^^^^^^^^^^^
  1703. JG> language".
  1704. John,
  1705.        I allways said, programming was GOOD CLEAN FUN ;-)
  1706.        Best regards,
  1707.        Mark Ouellet.
  1708. * Origin: Stuck with a Virus, Anyone heard of Windows??? (Fidonet 1:240/1.4)
  1709.  
  1710.  
  1711. --- Dogfight 2.06 #2
  1712.  
  1713.  
  1714. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1715.  
  1716. Conference 4
  1717. Date       12-22-91 20:35:30
  1718. From       Mark Ouellet
  1719. To         Rich Veraa
  1720. Subject    Re: Text search
  1721.  
  1722.     On 14 Dec 91, you, Rich Veraa, of 1:135/907.0 wrote...
  1723. RV> About a year ago, I believe you posted some code implementing a very
  1724.  
  1725. RV> fast search algorithm. I'm sure I put in in my archives, certain I'd
  1726.  
  1727. RV> need it one day.. Now, I do.. but search as I may, I can't for the life
  1728.  
  1729. RV> of my find it...
  1730. RV>
  1731. RV> Assuming you still have it, do you think you could repost it? It's been
  1732.  
  1733. RV> quite a while, so there are probably a lot of new people around that
  1734.  
  1735. RV> would appreciatge it too.
  1736. RV>
  1737. RV> It would really help me..  Thank you very much..
  1738. Rich,
  1739.        I rewrote TeeCee's program in Pascal, sorry but my
  1740. asm days are too far away so I wanted to make sure the
  1741. algorithm worked before I coded it in asm.
  1742.        I'll be posting it in the next two or three
  1743. messages. As it now stands it implements the FULL
  1744. Boyer-Moore algorithm with both skip tables calculated.
  1745.        I tried it on the NodeList.249 (Over 1 meg) and with
  1746. the whole file loaded in the disk cache on a 386-16, it took
  1747. about 5 seconds to find an 8 caracter string which I knew
  1748. appeared only at the very end of the file.
  1749.        BTW, this version is CASE-INSENSITIVE, you decide if
  1750. it should be case-sensitive or not.
  1751. I haven't had time to comment it yet but you should be
  1752. able to use it anyways.
  1753.        Some of the limitations of the asm version have
  1754. vanished with this rewrite, mainly the obligation for the
  1755. search buffer and the target string to be in the same
  1756. segment so eventhough I used a static buffer you could
  1757. easily use a dinamic one. This would allow to define a
  1758. buffer as large as permited by the free heap.
  1759.        Maybe TeeCee can do the honors and convert it back
  1760. to ASM ;-)
  1761.        Best regards,
  1762.        Mark Ouellet.
  1763. * Origin: Stuck with a Virus, Anyone heard of Windows??? (Fidonet 1:240/1.4)
  1764.  
  1765.  
  1766. --- Dogfight 2.06 #2
  1767.  
  1768.  
  1769. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1770.  
  1771. Conference 4
  1772. Date       12-22-91 21:55:10
  1773. From       Mark Ouellet
  1774. To         Rich Veraa
  1775. Subject    Boyer-Moore Search (1/4)
  1776.  
  1777.  { Here is part one, to be saved in BOYERMKO.PAS }
  1778. { BOYERMKO.PAS (22 December 1991) (Mark Ouellet) }
  1779. {    This unit provides facilities for searching a text for
  1780.     a target using the Boyer-Moore search method.
  1781.  Only peculiarity, the second skip structure is actually a
  1782.  string, this made sens since the second table has a 1:1
  1783.  ratio with the target length
  1784. }
  1785. {=======================================================}
  1786. unit BOYERMKO;
  1787. {=======================================================}
  1788. interface
  1789. Const
  1790.        MaxBuffer = 32768;
  1791. VAR
  1792.        MaxPos : Word;
  1793.        buffer : Array[1..MaxBuffer] of byte;
  1794.        Target : String;
  1795.        table1 : array[char] of byte;
  1796.        table2 : string;
  1797.  ch     : char;
  1798. procedure pause(message:string);
  1799. procedure MAKE_BOYER_MOORE_TABLE(var target: string;
  1800.                                 var table1; var table2;
  1801.                                 CaseSensitive:boolean);
  1802. function BOYER_MOORE_SEARCH(var text_array; start,
  1803.  text_length: word; var target: string; var table1;
  1804.  var table2; CaseSensitive:Boolean): word;
  1805. {====================================================}
  1806. implementation
  1807. uses crt;
  1808. {****************************************************}
  1809. procedure pause(message:string);
  1810. begin
  1811.        writeln;
  1812.        writeln(message);
  1813.    writeln('<Esc> to quit, <N> to skip to next file');
  1814.        while keypressed do ch:= readkey;
  1815.    while not keypressed do
  1816.        ;
  1817.        while keypressed do ch:= readkey;
  1818.    if ch=#27 then
  1819.                halt(0);
  1820. end;
  1821. procedure MAKE_BOYER_MOORE_TABLE(var target: string;
  1822.                                 var table1; var table2;
  1823.                                 CaseSensitive:Boolean);
  1824. var
  1825.        l_target : string absolute target;
  1826.        l_table1 : Array[char] of byte absolute table1;
  1827.        l_table2 : String absolute table2;
  1828.        reverse  : string;
  1829.        i,j,k : integer;
  1830.        ch : char;
  1831. begin { MAKE_BOYER_MOORE_TABLE }
  1832.  (*********************************************************)
  1833.  (* Creation of the first table, it contains values for   *)
  1834.  (* every caracter in the ascii table. All caracters not  *)
  1835.  (* contained in the search string are given the largest  *)
  1836.  (* possible value.                                       *)
  1837.  (*********************************************************)
  1838.  (*********************************************************)
  1839.  (* First set target to all uppercase if search is not to *)
  1840.  (* be sensitive                                          *)
  1841.  (*********************************************************)
  1842. { Continued in next message }
  1843. * Origin: Stuck with a Virus, Anyone heard of Windows??? (Fidonet 1:240/1.4)
  1844.  
  1845.  
  1846. --- Dogfight 2.06 #2
  1847.  
  1848.  
  1849. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1850.  
  1851. Conference 4
  1852. Date       12-22-91 21:57:30
  1853. From       Mark Ouellet
  1854. To         Rich Veraa
  1855. Subject    Boyer-Moore Search (2/4)
  1856.  
  1857.  { Here is part two, to be saved in BOYERMKO.PAS }
  1858. if not CaseSensitive then
  1859. for i := 1 to length(l_target) do
  1860. l_target[i] := upcase(l_target[i]);
  1861.  (**********************************************************)
  1862.  (* Initialize the table to the largest skip value ie:     *)
  1863.  (*             length(target)                             *)
  1864.  (**********************************************************)
  1865. fillchar(l_table1, sizeof(l_table1), target[0]);
  1866.  (**********************************************************)
  1867.  (* Replace values for caracters contained in target with  *)
  1868.  (* their distance from the right. Except for the last     *)
  1869.  (* caracter!!!                                            *)
  1870.  (**********************************************************)
  1871. for i := 1 to ord(target[0])-1 do begin
  1872. l_table1[target[i]] := ord(target[0])-i;
  1873. end;
  1874.  (**********************************************************)
  1875.  (* In case of a case insensitive search, the distance     *)
  1876.  (* should be the same for a caracter be-it upper-case or  *)
  1877.  (* lower-case. The distance is allways the right-most     *)
  1878.  (* occurance of the caracter                              *)
  1879.  (**********************************************************)
  1880. if not CaseSensitive then begin
  1881. for ch := 'a' to 'z' do begin
  1882. if l_table1[ch] < l_table1[upcase(Ch)] then begin
  1883. l_table1[upcase(Ch)] := l_table1[Ch];
  1884. end else begin
  1885. l_table1[ch] := l_table1[upcase(ch)];
  1886. end;
  1887. end;
  1888. end;
  1889.  (**********************************************************)
  1890.  (* Creation of the second table, it contains values for   *)
  1891.  (* each position in the search string. Essentially, each  *)
  1892.  (* value is the distance the distance to move left before *)
  1893.  (* a match can be found with the right right-sub-string   *)
  1894.  (* can be found again. The right sub-string starts with   *)
  1895.  (* the caracter immediately to the right of the current   *)
  1896.  (* position in the search string.                         *)
  1897.  (*                                                        *)
  1898.  (*   Example: ABCABCDE                                    *)
  1899.  (*                                                        *)
  1900.  (* if a miss occurs on the "E" and we are at position 10  *)
  1901.  (* in the text then we can move only one caracter to the  *)
  1902.  (* right since ALL WE KNOW is that the caracter at        *)
  1903.  (* position 10 is NOT AN "E".                             *)
  1904.  (*                                                        *)
  1905.  (* If the miss occurs on the "D" then we can move 8       *)
  1906.  (* positions to the right since we now know that the "E"  *)
  1907.  (* matched but there are no more "E"'s in the search      *)
  1908.  (* string. All positions to the left of "D" would also    *)
  1909.  (* generate a move of 8 positions since the substring     *)
  1910.  (* "DE" does not repeat either nor does "CDE" then "BCDE" *)
  1911.  (* etc... since any string in this case is a superset of  *)
  1912.  (* it's right substrings                                  *)
  1913.  (*                                                        *)
  1914.  (* if the search string had been:                         *)
  1915.  (*                                                        *)
  1916.  (*     KFGABCABC                                          *)
  1917.  (*                                                        *)
  1918.  (* then a miss on the first "C" from the left would       *)
  1919.  (* generate a move of only three since we would then know *)
  1920.  (* that the text matched "ABC" and what miss-matched with *)
  1921.  (* the first "C" might be a "G". *) Both values are used  *)
  1922.  (* when a miss occurs, the greatest of the two values is  *)
  1923.  (* then used to move the search string forward            *)
  1924.  (**********************************************************)
  1925. { continued in next message }
  1926. * Origin: Stuck with a Virus, Anyone heard of Windows??? (Fidonet 1:240/1.4)
  1927.  
  1928.  
  1929. --- Dogfight 2.06 #2
  1930.  
  1931.  
  1932. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1933.  
  1934. Conference 4
  1935. Date       12-22-91 21:58:40
  1936. From       Mark Ouellet
  1937. To         Rich Veraa
  1938. Subject    Boyer-Moore Search (3/4)
  1939.  
  1940.  { Here is part three, to be saved in BOYERMKO.PAS }
  1941.  (**********************************************************)
  1942.  (* Since we want the right-most position of the           *)
  1943.  (* sub-string, set a new string that is a reverse of the  *)
  1944.  (* original.                                              *)
  1945.  (**********************************************************)
  1946. l_table2 := target;
  1947. reverse := target;
  1948.  (**********************************************************)
  1949.  (* now reverse l_table2 into reverse                      *)
  1950.  (**********************************************************)
  1951. for i := 0 to length(target)-1 do
  1952. if CaseSensitive then
  1953. reverse[i+1] := target[ length(target) - i]
  1954. else
  1955. reverse[i+1] := upcase(target[ length(target) - i]);
  1956.  (**********************************************************)
  1957.  (* now compute sub-string positions, as soon as we get a  *)
  1958.  (* max-length for any sub-string, all subsequent          *)
  1959.  (* sub-string are also max-length                         *)
  1960.  (**********************************************************)
  1961. for i := length(target)-1 downto 1 do begin
  1962.    if pos(copy(reverse,1,
  1963.    length(target)-i),copy(reverse,2,300))>0 then
  1964.      l_table2[i] := chr(pos(copy(reverse,1,
  1965.      length(target)-i),copy(reverse,2,300)))
  1966. else
  1967. l_table2[i] := chr(length(target));
  1968. end;
  1969.  (**********************************************************)
  1970.  (* Last position is allways a move of at most 1 position  *)
  1971.  (**********************************************************)
  1972. l_table2[length(target)] := chr(1);
  1973. end; { MAKE_BOYER_MOORE_TABLE }
  1974. {************************************************************}
  1975. function BOYER_MOORE_SEARCH(var text_array; start,
  1976.                            text_length: word; var target:
  1977.                            string; var table1; var table2;
  1978.                            CaseSensitive:Boolean): word;
  1979. var
  1980.  l_text_array : array[1..maxbuffer] of char
  1981.      absolute text_array;
  1982. i,j, offset : word;
  1983. match, found : boolean;
  1984. distance, distance1, distance2 : byte;
  1985. l_table1 : array[char] of byte absolute table1;
  1986. l_table2 : record
  1987.   dummy : byte;
  1988.   distance : array[1..255] of byte;
  1989.   end absolute table2;
  1990. begin { BOYER_MOORE_SEARCH }
  1991. i := start;
  1992. found := false;
  1993.  offset := 0;
  1994. distance := 0;
  1995. J := LENGTH(TARGET);
  1996.  while ((i+distance) < text_length-length(target))
  1997.  and not found do begin
  1998. inc(i, distance-(length(target)-j));
  1999. j := length(target) ;
  2000.    match := true;
  2001. while (j > 0) and match do begin
  2002. if not CaseSensitive then
  2003. match := (target[j] = upcase(l_text_array[i+j]))
  2004. else
  2005. match := (target[j] = l_text_array[i+j]);
  2006. if match then dec(j);
  2007. end;
  2008.    found := match;
  2009. if not found then begin
  2010. distance1 := l_table1[l_text_array[i+j]];
  2011. distance2 := l_table2.distance[j];
  2012. end;
  2013. if distance1 < distance2 then
  2014. distance := distance2
  2015. else
  2016. distance := distance1;
  2017. end;
  2018.    boyer_moore_search := ord(found) * (i);
  2019. end; { BOYER_MOORE_SEARCH }
  2020. {************************************************************}
  2021. end.
  2022. { next message contains a test program }
  2023. * Origin: Stuck with a Virus, Anyone heard of Windows??? (Fidonet 1:240/1.4)
  2024.  
  2025.  
  2026. --- Dogfight 2.06 #2
  2027.  
  2028.  
  2029. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2030.  
  2031. Conference 4
  2032. Date       12-22-91 22:01:00
  2033. From       Mark Ouellet
  2034. To         Rich Veraa
  2035. Subject    Boyer-Moore Search (4/4)
  2036.  
  2037.  { Here is the test program, hope you have fun with it }
  2038. PROGRAM TEST_BOYER_MOORE;
  2039. USES boyermko, crt, dos;
  2040. VAR
  2041.    index1, index2 : byte;
  2042.    HEX : STRING;
  2043.    startx,starty:byte;
  2044.    CommandStr : String;
  2045.    SearchFileName : PathStr;
  2046.    SearchFile : File;
  2047.    CaseSensitive : boolean;
  2048.    Ch : char;
  2049.    Resultat : Boolean;
  2050.    LongBufPos : Longint;
  2051.    bufPointer : word;
  2052.    SizeRead, i, J : word;
  2053.    LONGEUR,MIN,MAX : WORD;
  2054.    B4, DURING, AFTER:WORD;
  2055.    DirInfo : SearchRec;
  2056.    Dir     : DirStr;
  2057.    Name  : NameStr;
  2058.    Ext   : ExtStr;
  2059.    OldAttr : word;
  2060. BEGIN
  2061.    CommandStr := string(Ptr(PrefixSeg, $80)^);
  2062.    clrScr;
  2063.    TEXTCOLOR(WHITE);
  2064.    writeln;
  2065. write('Enter Search text :');
  2066. readln(Target);
  2067. writeln;
  2068. write('Enter File to search:');
  2069. readln(SearchFileName);
  2070. writeln;
  2071. write('Case sensitive search (Y/N)? ');
  2072. read(ch);
  2073. CaseSensitive := (ch in ['Y','y']);
  2074. MAKE_BOYER_MOORE_TABLE(Target, table1, table2, CaseSensitive);
  2075. WRITELN;
  2076. fsplit(SearchFileName, Dir, Name, Ext);
  2077. findfirst(SearchFileName, anyfile, DirInfo);
  2078. while DosError = 0 do begin
  2079.        if not (DirInfo.Attr in [Directory, VolumeId])
  2080.        and (DirInfo.Size > 0) then begin
  2081.            SearchFileName := Dir + DirInfo.Name;
  2082.            writeln('Searching ', SearchFileName);
  2083.            Assign(SearchFile, SearchFileName);
  2084.            GetFattr(SearchFile, OldAttr);
  2085.            SetFattr(SearchFile, Archive);
  2086.            {$I-}
  2087.            reset(SearchFile,1);
  2088.            {$I+}
  2089.            if ioResult<>0 then begin
  2090.                writeln('Erreur a l''ouverture du fichier...');
  2091.                pause('Appuyer sur une touche pour terminer...');
  2092.                Halt(Word(-1));
  2093.            end;
  2094.            LongBufPos := 0;
  2095.            repeat
  2096.                Seek(SearchFile, LongBufPos);
  2097.                blockread(SearchFile, Buffer, MaxBuffer, SizeRead);
  2098.                MaxPos := SizeRead - ord(Target[0]);
  2099.                BufPointer := 0;
  2100.                repeat
  2101.                i := BOYER_MOORE_SEARCH(Buffer, BufPointer, SizeRead,
  2102.                Target, table1, table2, CaseSensitive);
  2103.                if (i > 0) then begin
  2104.                    BufPointer := i+length(target);
  2105.                    ClrScr;
  2106.                    textcolor(white);
  2107.                    Writeln('File: ', SearchFileName,
  2108.                    ' Position: ',LongBufPos+i);
  2109.                    Writeln;
  2110.                    IF i < 80 THEN
  2111.                        B4 := 1
  2112.                    ELSE
  2113.                        B4 := i - 80;
  2114.                    textcolor(lightred);
  2115.                    j := B4;
  2116.                    WHILE (j <= i) and (j < SizeRead) do begin
  2117.                        WRITE(chr(Buffer[j]));
  2118.                        INC(j);
  2119.                    END;
  2120.                    textcolor(white);
  2121.                    during := j;
  2122.                    WHILE (J < SizeRead)
  2123.                    and (j <= i+LENGTH(TARGET)) do begin
  2124.                        WRITE(chr(Buffer[j]));
  2125.                        INC(j);
  2126.                    END;
  2127.                    textcolor(lightred);
  2128.                    AFTER := J;
  2129.                    WHILE (J < SizeRead)
  2130.                    and (j < B4+319) do begin
  2131.                        WRITE(chr(Buffer[j]));
  2132.                        INC(j);
  2133.                    END;
  2134.                    TEXTCOLOR(WHITE);
  2135.                    pause('Press return for next match...');
  2136.                    if ch in ['N','n'] then
  2137.                        SizeRead := 0;
  2138.                    end
  2139.                until (i = 0) or (BufPointer > MaxPos) or (SizeRead=0);
  2140.                LongBufPos := LongbufPos + MaxPos;
  2141.            until SizeRead < MaxBuffer;
  2142.            SetFAttr(SearchFile, OldAttr);
  2143.            Close(SearchFile);
  2144.        end;
  2145.        findnext(DirInfo);
  2146.    end;
  2147.    textcolor(white);
  2148.    writeln('Search complete....');
  2149. END.
  2150. {       Best regards,
  2151.        Mark Ouellet.
  2152. }
  2153. * Origin: Stuck with a Virus, Anyone heard of Windows??? (Fidonet 1:240/1.4)
  2154.  
  2155.  
  2156. --- Dogfight 2.06 #2
  2157.  
  2158.  
  2159. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2160.  
  2161. Conference 4
  2162. Date       12-22-91 22:04:00
  2163. From       Mark Ouellet
  2164. To         Patrick Mabie
  2165. Subject    Re: Upgrade
  2166.  
  2167.     On 13 Dec 91, you, Patrick Mabie, of 1:268/206.1 wrote...
  2168. PM> Yea I know the feeling , but I was reading a message on this echo,
  2169. PM> saying that you sould at lease give the new compiler a chance 100 hours
  2170.  
  2171. PM> , so I did I find it to be very good compiler, but 5.5 had some neat
  2172.  
  2173. PM> feathers that was left out for 6.0......
  2174. Patrick,
  2175.        What features ????
  2176.        Best regards,
  2177.        Mark Ouellet.
  2178. * Origin: Stuck with a Virus, Anyone heard of Windows??? (Fidonet 1:240/1.4)
  2179.  
  2180.  
  2181. --- Dogfight 2.06 #2
  2182.  
  2183.  
  2184. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2185.  
  2186. Conference 4
  2187. Date       12-22-91 22:04:20
  2188. From       Mark Ouellet
  2189. To         Vince Laurent
  2190. Subject    Re: Undeletable files
  2191.  
  2192.     On 15 Dec 91, you, Vince Laurent, of 1:382/11.0 wrote...
  2193. DM>> That's very strange - on my system, those files aren't
  2194. DM>> marked with special attributes.
  2195. VL> But what are those files?
  2196. Vince,
  2197.        They are commonly called SPILL-FILES, your computer
  2198. memory serves as a window under which the complete file
  2199. moves, what fits inside the window, you have in memory, what
  2200. lies before the window is put into a Spill-File and so is
  2201. what lies after the window.
  2202.        When you move from the begining of the code to the
  2203. end, you are slideing the window, thus pascal stores old
  2204. lines (Those that were at the top of your window into
  2205. spill-file1, and loads new lines from spill-file2 to fill
  2206. memory.
  2207.        Most word processors worked like this, at least
  2208. VolksWriter used to work like this. Someone mentionned
  2209. something about TP (in a reply to your question) that
  2210. indicated this might be what was happening since TP can load
  2211. files as large as 1Meg and even multiple files.
  2212.        I suspect it might rather be the editors memory that
  2213. is saved to disk to make room for the program (You did
  2214. mention this happened when you tried running one of your
  2215. programs from the IDE)
  2216.        Best regards,
  2217.        Mark Ouellet.
  2218. * Origin: Stuck with a Virus, Anyone heard of Windows??? (Fidonet 1:240/1.4)
  2219.  
  2220.  
  2221. --- Dogfight 2.06 #2
  2222.  
  2223.  
  2224. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2225.  
  2226. Conference 4
  2227. Date       12-22-91 22:11:40
  2228. From       Mark Ouellet
  2229. To         Mike Wilson
  2230. Subject    Re: Overlay Error on EMS
  2231.  
  2232.     On 15 Dec 91, you, Mike Wilson, of 1:130/28.0 wrote...
  2233. MW> I am having a problem with a overlay program I am using.  It seems to
  2234.  
  2235. MW> work fine with the simple ovrinit bu when I try to load the ovr into
  2236. EMS
  2237. MW> the whole sstem locks, requiring a reset button.  I have other programs
  2238.  
  2239. MW> that I run using the ovr in EMS so the EMS software isn't the problem.
  2240.  
  2241. MW> Anyone have any suggestions as to what might be the problem?  I do not
  2242.  
  2243. MW> recieve ANY Overlay error messages and I do have the code to show Ovr
  2244.  
  2245. MW> errors in the program.
  2246. Mike,
  2247.        post the part that does the actual ovrmanager's
  2248. initialisation and maybe someone will spot the problem.
  2249.        Best regards,
  2250.        Mark Ouellet.
  2251. * Origin: Stuck with a Virus, Anyone heard of Windows??? (Fidonet 1:240/1.4)
  2252.  
  2253.  
  2254. --- Dogfight 2.06 #2
  2255.  
  2256.  
  2257. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2258.  
  2259. Conference 4
  2260. Date       12-22-91 22:19:00
  2261. From       Mark Ouellet
  2262. To         Joshua Kersey
  2263. Subject    Re: .PCX files
  2264.  
  2265.     On 13 Dec 91, you, Joshua Kersey, of 1:124/3108.0 wrote...
  2266. JK> -/-Does anyone know of any code that will load mode 19 (320x200x256)
  2267.  
  2268. JK> -/-PCX files? If not, does anyone know the format of these files?
  2269. JK> -/-Thanks, Chris.
  2270. JK>
  2271. JK> Chris, maybe I'm dreaming, but (320x200x256) is mode 13.
  2272. JK> Hold on, lemme confirm this.
  2273. JK>
  2274. JK> Yeap, mode 13.
  2275. Joshua,
  2276.        in my book, $13 (allthough he doesn't specify it's
  2277. hex) is 19 decimal.
  2278.        Best regards,
  2279.        Mark Ouellet.
  2280. * Origin: Stuck with a Virus, Anyone heard of Windows??? (Fidonet 1:240/1.4)
  2281.  
  2282.  
  2283. --- Dogfight 2.06 #2
  2284.  
  2285.  
  2286. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2287.  
  2288. Conference 4
  2289. Date       12-23-91 12:35:20
  2290. From       Mark Ouellet
  2291. To         Jud Mccranie
  2292. Subject    Re: Fast File Read
  2293.  
  2294.     On 15 Dec 91, you, Jud Mccranie, of 1:370/520.0 wrote...
  2295. TC>> BlockRead used correctly is as fast as anything I have seen.
  2296. TC>> I'd like to see your code before making too many suggestions
  2297. TC>> but I suspect you may be reading small records one at a time.
  2298. TC>> Naturally that would be slow.
  2299. JM> If you want to see SLOW try reading a file of char!  It sure would be
  2300. JM> nice if the natural way of file of type or file of record_type would
  2301. JM> also be fast.
  2302. Jud,
  2303.        take a look at settextbuf, assigning a large read
  2304. buffer for text I/O can speed it up a lot. I programed a
  2305. little thing to remove ANSI sequences form a text file and
  2306. tested it using an > 1Meg file and qas quite pleased with
  2307. the speed even though I had to read char/char.
  2308.        Best regards,
  2309.        Mark Ouellet.
  2310. * Origin: Stuck with a Virus, Anyone heard of Windows??? (Fidonet 1:240/1.4)
  2311.  
  2312.  
  2313. --- Dogfight 2.06 #2
  2314.  
  2315.  
  2316. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2317.  
  2318. Conference 4
  2319. Date       12-23-91 12:57:50
  2320. From       Mark Ouellet
  2321. To         Greg Smith
  2322. Subject    Re: TP 6.0 bug list update
  2323.  
  2324.     On 12 Dec 91, you, Greg Smith, of 1:104/441.8 wrote...
  2325. GS> here's a sample of what I do:
  2326. GS>
  2327. GS> SetIntVec($09, OldInt09);
  2328. GS> 1 SwapVectors;
  2329. GS> Exec(GetEnv('COMSPEC'),'');
  2330. GS> 2 SwapVectors;
  2331. GS> SetIntVec($09, KBM_Handler);
  2332. GS>
  2333. GS> I found the problem using turbo debugger and monitoring the exitproc
  2334. GS> variable.  Apparently, after point one the exitproc was reset to the
  2335. GS> system unit's (or some standard exitproc).  After point two the exitproc
  2336. GS> was not set back to my own procedure.  This is with TP 6.0.
  2337. But Greg,
  2338.        from the above code it seems *YOU* reset int09 to
  2339. it's original value before calling swap vectors so there
  2340. would be nothing to do on return. I beleive swapvector would
  2341. reset it to your own routine had it been pointing at your
  2342. own routine.
  2343.        Best regards,
  2344.        Mark Ouellet.
  2345. * Origin: Stuck with a Virus, Anyone heard of Windows??? (Fidonet 1:240/1.4)
  2346.  
  2347.  
  2348. --- Dogfight 2.06 #2
  2349.  
  2350.